1. Fields of the Invention
The present invention generally relates to detecting a source-related risk. More particularly, the present invention relates to detecting a source-related risk during a development of an object.
2. Description of the Prior Art
With a trend of sharing and reusing, objects are composed of pre-existing materials or sub-objects created by a another person (e.g., a co-worker, a programmer working in a different company, etc.). This trend (i.e., sharing and reusing pre-existing materials) applies in software development. In a new software development, developers often leverage pre-existing materials (i.e., any material that has existed before a current development), such as open source code and a third party picture, with benefit of accelerating development progress, saving creation effort, or achieving good quality. However, leveraging pre-existing materials, especially pre-existing code, to the software development may also introduce source-related risks (i.e., a copyright issue, a licensing issue, a code pedigree (i.e., code coming from many different sources) issue).
An improper operation on source information of code increases a risk of code contamination, ownership and responsibilities, and increases a difficulty of sharing and reusing the code. Because of the improper operations (e.g., deleting developer or author's information) on code, a use of pre-existing code, especially code in a public domain, always carries a high risk of code contamination, both in a form of bugs inadvertently created and in a form of virus or worms intentionally produced. A programmer may intentionally delete author information or other source information (e.g., a copyright or licensing term) from open source code (i.e., source code is open to public; no royalty or other fee for selling, distributing, modifying and redistributing the source code; the source code can be used in anywhere) when adding the open source code to his or her current project. Because of the improper operations (e.g., deleting a copyright term), no matter by an accident or by an intention, during code development, developers may not be aware of a source-related risk or get any alert associated with the source-related risk, so that they have no confidence to share and reuse code.
SCM (Software Configuration Management) tools, such as CVS (Concurrent Versions System), IBM® ClearCase™ and Subversion™, can record developers and revisions (i.e., modifications on code) during check-in (i.e., putting code in a repository)/check-out (i.e., obtaining code from a repository) in a development of a software project. However, the SCM tools have a limitation of recording source information only at the moment of the check-in/check-out. That is, the SCM tools only check differences between a check-out version (i.e., code when being obtained) and a check-in version (i.e., code when being stored in a repository), so SCM tools do not check/trace all changes made between a check-out and a check-in. Furthermore, the SCM tools do not detect any source-related risk such as a copyright issue.
Black Duck™ Software is a provider of products and services for accelerating software development through a managed use of open source and third party code. Black Duck™ products and services can help mitigate risks and challenges associated with open source code, including hidden license obligation, security vulnerability, etc.
Although Black Duck™ Software provides tools such as managing open source and assuring license compliance, Black Duck™ Software only focuses on content of an object (e.g., code) and does not focus on a wider scope including operations to the content (e.g., modifying code, deleting code, inserting new code). Black Duck™ Software performs content comparison (i.e., comparing currently developed code and open source code) for a batch of files at a scheduled time. Thus, Black Duck™ Software works off-line.
Hailpern et al. (US Patent Application Publication No. 2008/0021922; hereinafter “Hailpern”) provides a summary of source information of sub-objects in an object. This source information is tracked throughout a development of the object. However, Hailpern only tracks and records the source information but does not provide any determination (e.g., whether an operation on object causes a source-related risk) or does not generate an alert for a source-related risk.
There are also many traditional tools on defect detection, such as RAD (Rapid Application Development), CodeWizard and PC-Lint. These traditional tools focus on detecting function-level code defects (e.g., memory release) and do not detect any source-related risk. Therefore, the traditional tools usually collect information from source code by a static code analysis (i.e., an analysis of computer software that is performed without actually executing programs built from the software) or a dynamic program analysis (i.e., an analysis of computer software that is performed with executing programs built from that software on a real or virtual processor), compare a result of the static code analysis and a result of the dynamic software analysis, and generate a result of the comparison in a summary or highlight on source code. However, the traditional tools do not collect information from operations on code (e.g., inserting new code, modifying code, deleting code, etc.) and from source information of the code (e.g., a copyright term of the code, a licensing term of the code, author or developer of the code, etc.).
Moreover, in current software development projects, developers are often required at the end of software development to sign a “Certificate of Originality”(COO) stating which parts of the code of the software are their own creation, and which parts are from the Open Source or from other developers/authors. Due to a lack of an effective and reliable mechanism to maintain and track source information about code or due to a lack of an effective and reliable mechanism to remind a developer a source-related risk during development, this process (i.e., a process obtaining originality information of each code) usually takes 1-2 months to complete, which is both burdensome and costly. If the source-related risk can be detected and alerted to a developer during software development, the process will be more accelerated and easily since source-related risks can be greatly reduced whenever a source-related risk occur.
In the development of multimedia files (e.g., web pages, audios or videos), there is a critical need to track source information of various elements in a file, and then to determine whether there is a risk or not (e.g., whether the file contains any content whose access is either prohibited (e.g., illegally copied music) or restricted (e.g., using a trademarked logo after one's access rights have expired)). Without such a mechanism, people will be uncomfortable or unconfident to use the elements, which may violate copyrights, trademarks, licensing terms, etc.
Thus, it is highly desirable for a method and system directed to detect a source-related risk and to generate an alert whenever a source-related risk is detected.